Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL), are cryptographic protocols that provide communication security for transmitted data. TLS and SSL utilize asymmetric cryptography for authentication during a key exchange, symmetric cryptography to encrypt application layer data, and message authentication codes (MACs) to ensure the integrity of each transmitted message. Many different versions of TLS and SSL are widely used for an increasing variety of applications, including web browsing, electronic mail, instant messaging, and voice-over-IP (VoIP) as a few examples. TLS is an Internet Engineering Task Force (IETF) standards track protocol, which was first defined in IETF Request for Comments (RFC) 2246 as TLS 1.0, updated in IETF RFC 4346 as TLS 1.1, and again updated as TLS 1.2 in both RFC 5246 and RFC 6176. TLS is based upon versions 1.0, 2.0, and 3.0 of SSL.
As used herein, the terms “transport layer security protocol” or “encryption protocol” may be used generically to describe a TLS protocol, SSL protocol, or any other cryptographic protocol used for encrypting application layer data sent over a communications network (e.g., the Internet). Similarly, the terms “secure connection” or “encrypted connection” may be used to refer to communications between two electronic devices utilizing an encryption protocol to obfuscate some or all of the data (e.g., a payload such as application layer data or an encapsulated packet, etc.) sent over the connection.
As the world has become more interconnected and the Internet has become more essential in people's day-to-day lives, increasing amounts of sensitive data (e.g., financial account numbers, secret and confidential business or government information, personal photographs, etc.) are being transmitted over the Internet and thus, the use of and reliance upon transport layer security protocols to secure the transmission of this sensitive data has similarly increased. However, this shift has drawn the attention of attackers, who now increasingly seek to find ways to attack these encrypted communications to gain access to the sensitive data.
In addition to attacking the design vulnerabilities of transport layer security protocols (e.g., the “BEAST” attack preying upon a weakness in Cipher Block Chaining (CBC) Initialization Vector (IV) chaining used in SSL and TLS v1.0, the “Padding Oracle On Downgraded Legacy Encryption” or “POODLE” attack, the “triple-handshake” attack, etc.), another prominent target of attackers has been the different implementations of the transport layer security protocols used to create and utilize the secure connections.
Implementations of the SSL and TLS protocols are very typically very complex because they may support various versions, many cipher suites, and many cryptographic blocks, all of which may be defined by different specifications. Further, the session data structures needed to be implemented for these implementations are not trivial. As a result, the implementations are often subject to many bugs.
These implementation vulnerabilities are particularly dangerous because of the severity of the consequences of an exploit. Recently-detected implementation vulnerabilities have revealed that simple bugs in this library code can be exploited to acquire passwords stored in the memory of a server and/or gain the ability to cause remote code execution. Further, implementation bugs are often present in a library for many years allowing long-term attacks, and the risks can be even higher in open source libraries, which can easily be inspected and analyzed by attackers, allowing bugs to more readily be discovered. Moreover, many of the attacks are not easily discoverable by victims, as they often do not create easily-detectable side-effects.
As a few examples, the Java Secure Socket Extension (JSSE) SSL/TLS implementation has been found to be vulnerable to Bleichenbacher-type attacks. Mozilla's Network Security Services (NSS) library, used by the Chrome Browser and Firefox Browser (among others), was found to be vulnerable to yet another Bleichenbacher-type attack, named “BERserk.” Apple's SecureTransport implementation, which is used by both iOS and OS X, was discovered to have a “goto fail” vulnerability. GNU Transport Layer Security Library (GNUTLS) implementations were found to be vulnerable to a man-in-the-middle attack. The Microsoft SChannel library, used by Windows, was found to be vulnerable to a “WinShock” attack that provides remote code execution vulnerability and/or server verification bypass. Moreover, both the SChannel library and the OpenSSL library were found to be vulnerable to a “Freak” attack, and perhaps most notably, the OpenSSL library was found to be vulnerable to a “Heartbleed” attack due to a bug in an implementation of a heartbeat extension that leads to a host with the vulnerable library (and the enabled heartbeat feature) to leak certain server memory content. This memory leak is sent in a heartbeat response packet, and can contain very sensitive data from the host, including cookies, passwords, SSL certificates, etc. Further, the attack can be repeated many times by an attacker to read more memory space. Such implementation vulnerability attacks are expected to continue to be discovered by attackers in increasing numbers.
In addition to just being vulnerable to stolen data or remotely-executed code due to a vulnerable implementation, the detection of a vulnerability creates significant amounts of other problems. Typically, upon the widespread dissemination of the news that a vulnerability has been found, a server operator may have to investigate whether their particular utilized implementation and/or software version is vulnerable, potentially shutdown their server immediately to avoid being compromised by an existing or future attacker, attempt to find a patch for the implementation, determine whether the patch will cause any further problems for their systems, apply the patch, determine whether the patch was successful in addressing the vulnerability, and then restart the server. Thus, discovered vulnerabilities result in a tremendous amounts of work for network administrators, and perhaps more importantly, can result in significant amounts of downtime for the affected servers, thus affecting active clients and potentially leading to violations of Service-level agreement (SLA).
Accordingly, there is a strong and growing need for techniques to protect against transport layer security implementation vulnerabilities and the negative consequences resulting from their detection.